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Abstract. The aim of the paper is to provide a solution which increases the security of a mobile 
environment for both individuals and for workers in an enterprise. The proposed solution adapts 
Shamir’s approach for sharing a secret for encryption key management. One part of the key is 
stored on a Bluetooth or NFC wristband or on an enterprise server, while a mobile device is used 
to store all the rest. The approach can be applied for both securing documents and voice data. 
The solution is supported by a mathematical formality which is missing in the currently known 
advice within cryptographic folklore. 
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1 Motivation 

Despite the fact that nobody would dispute that the storage of cryptographic keys is 
a very important part of data protection, there has been no significant progress in this 
direction as yet. Essentially, all advice is at the cryptographic folklore level. A digest of 
advice can, for example, be found in OWASP (WEB, a): 

- Ensure that any secret key is protected from unauthorized access. 

- Define a key lifecycle. 

- Store unencrypted keys away from the encrypted data. 

- Use independent keys when multiple keys are required. 

- Protect keys in a key vault. 

- Document concrete procedures for managing keys through the lifecycle. 

- Build support for changing keys periodically. 

- Document concrete procedures to handle a key compromise. 

- Rekey data at least every one to three years. 
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- Protect any keys used to secure cardholder data against disclosure and misuse. 

- Fully document and implement all key-management processes and procedures for 
cryptographic keys used for encryption of cardholder data. 

The abovementioned advice mandates that key management processes should cover 
8 specific key lifecycle steps: 

1. Generation of strong cryptographic keys. 

2. Secure cryptographic key distribution. 

3. Secure cryptographic key storage. 

4. Periodic cryptographic key changes. 

5. Retirement or replacement of keys as deemed necessary when the integrity of 
the key has been weakened or keys are suspected of being compromised. 

6. Split knowledge and establishment of dual control of cryptographic keys. 

7. Prevention of unauthorized substitution of cryptographic keys. 

8. Requirement for cryptographic key custodians to sign a form stating that they 
understand and accept their key-custodian responsibilities. 

The fact that the advice on the storage of keys is at the folklore level is partially 
due to the lack of an adequate description of the situation which can fit into some 
mathematical formalism. 

But, the problem is that the standard user is unable to either remember the folklore 
advice or to follow it. It means that a solution which is sufficiently simple has to be 
found, while taking into account all of the abovementioned restrictions. 

Our aim is to show how it’s possible to ensure that both individual users and work¬ 
ers at an enterprise don’t have to puzzle over issues which are not within their compe¬ 
tence. To reach this aim the authors have adopted Shamir’s approach for sharing a secret 
(Shamir, 1979): the secret is some data D. Divide D into n pieces I?i, D 2 ,..., Dn in 
such a way that: 

(1) knowledge of any x or more Di pieces makes D easily computable; 

(2) knowledge of any x — 1 or fewer Di pieces leaves D completely undetermined (in 
the sense that all its possible values are equally likely). 

The authors propose considering the use of an encryption key as the secret data D from 
Shamir’s approach for encryption key management in a mobile environment. We need 
n = X = 2. 

2 Document Encryption 

Split the encryption key k into two parts, ki and ^ 2 , so that there is no possibility 
of restoring a key if any of the parts are missing. A Bluetooth or NFC (Near Field 
Communication) wristband is used for storing the encrypted k 2 - A smartphone is used 
for storing the remainder. That is all that the user has to care for. The whole document 
encryption process will be carried out by a mobile application on the smartphone. 

Now we will describe the details that a user friendly application loaded into a smart¬ 
phone must provide. At first a decision should be made as to which cryptosystems will 
be used. 
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The authors propose that two different cryptosystems should be used for increasing 
security. Nowadays RC4-like stream cipher (Spritz) is considered to be good enough 
(see the latest research Rivest, Schuldt (2014), Ro§ie (2015)). We do not insist on one 
specific cryptosystem as best of all. For more stream ciphers see (WEB, b) and see 
(WEB, c) for block ciphers. We recommend one system should be used for document 
encryption, the second one — for communication. Thus two different cryptosystems 
are loaded into the smartphone: 


•fti — 

•^2 = {1^2,02, K2, £2,1^2) 


Here for both i G {1,2} 

-Pi — plaintext space; 

- Ci — ciphertext space; 

- Ki — key space; 

- X K -G Ci — a set of encryption functions; 

- Vi : C X K ^ Vi — a set of decryption functions 

and for every plaintext x G Vi, every key k G Ki is valid 

Vi{£i{x, k), k) = X . 

If one cryptosystem .fti is used instead of M.i and M 2 then Ki ^ K 2 at least. 

Eor every document Di a cryptosystem .Si key Kn is generated, which is used for 
document Di encryption, namely. 


Key Kii is split into two independent parts and KT'} so that 

iT,i=2l(iT'i,iT"), 

where 21 — algorithm, restoring key Kn, if its parts and iT'} are given. The re¬ 
quirement is that key Kn cannot be restored, if only one part of the key parts K[^, or 
iT'} is known. 

Cryptosystem M 2 keys and K'^ are generated. The halves of key Kn are en¬ 
crypted, namely. 


S,^=£2{K[„K[^), 

S,2=£2{K':^,K'^2)- 

H', iT' 2 ) ^re stored in the smartphone, while iT' 2 , Sa are stored in the Bluetooth 
or NEC wristband (see Eig.L). 
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Fig. 1. Splitting of the key. 

If a user wants to read the document Vi, then the user has to enter the password (a 
security measure for the situation where a mobile device is also used by other persons, 
let’s say, family members), and only then does the application address the wristband, 
loading itr' 2 , Sa, and decrypting the halves of key Kn 

Kl,=V2{Sn,Kl^), 

restoring the document’s Di encrypted key 

and finally decrypting the document 

Di = Vi{D'i,K,{). 


As soon as the document is decrypted, the application deletes (destroys) all the data 
used for the decryption of the document which should not be stored on the mobile de¬ 
vice, namely, the keys Kn , , Ar' 2 , K'^ and encrypted keys Sn, Sa . Work with 

memory must be organized depending of the specific hardware to really destroy mis¬ 
sion critical data. Decrypted document Di is deleted (destroyed) when the user finishes 
reading the document. Only D’i, Ki 2 , Sn should remain on the smartphone after the 
particular document has been read (see Fig. 2.). Otherwise after reading the document 
becomes unsecure. 
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Fig.2. Reading of document Di. 

Where a mobile device has been lost, unauthorized access to encrypted documents 
is not possible, assuming that the wristband has also not been lost. Our solution does 
not exclude the usage of other security measures, see, for example (WEB, d); Gorbans, 
Kulesovs, Straujums, Buis (2015). 

3 Encryption of Enterprise Documents and Voice Calls 

Users can use their connection with an enterprise server instead of the wristband for 
the encryption of enterprise documents. This eliminates the risk arising from the loss of 
a wristband and allows the disabling of communication with the lost or stolen mobile 
device. In this case, the keys are generated on a secure enterprise server. iT '2 Sa 
are kept there now as well. Using this approach, a user has to take into account that 
encrypted documents are not available offline, but this issue should be solved separately. 

As opposed to the reading of documents, voice calls should be encrypted and de¬ 
crypted in real time to avoid delays. In general, there are no serious barriers to encrypt¬ 
ing voice calls nowadays. It should be noted, that mobile networking already goes from 
an analogue to a digital mode, and traffic is encrypted if the call moves within an LTE 
network. But, the encryption process is controlled by the carrier’s mobile tower. That is 
why an enterprise cannot be 100% sure that encryption has really taken place between 
the phone and the tower, and that the call has also been transferred in an encrypted way 
between other towers, especially if they belong to another carrier. 

In order to provide enterprise users with operative networking, we recommend a 
solution similar to the one already proposed for private needs. Two different cryptosys¬ 
tems are uploaded to the server: 

■S3 = {'P31C31 K 3 ,£ 3 ,'D 3 ), 

•S4 = {1^4, Cij K4, £4,1)4). 
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Let’s assume that communication should be established between v employees. The 
m sets are prepared for each pair of i, j employees. The first set is used for the first call, 
the second set — for the second call, etc. If i employee calls j employee for time k, 
then the application automatically loads the fc-th set from the wristband and 

renews the key This key is used for call encryption and decryption. When the call 
is completed or if the connection has been unsuccessful, then set , S'* 2 

is deleted. 

The various key sets are generated Klj^, Klj^, where if kg is the 

cryptosystem .^3 key used for the encryption of a call t between i and j employees. 
Keys if kg are divided into two independent parts if kg and if^jg. It is done in such a 
way that 

ifkg = 2t(ifi;3,if^;), 

where 21 is an algorithm that renews key if kg if its parts, if kg and if|jg, are given. 

Keys if|j 4 and of the cryptosystem are generated. The halves of key if|jg 
are encrypted, namely, 


^ij2 = 

and Skg are kept on the smartphone while if *^4 and 81^2 are kept on the wristband. 

There is one encryption characteristic worth mentioning. If there is no need to keep 
a recorded call in an encrypted way, then such a protocol is not needed either. In this 
case it is enough to choose one cryptosystem .^3 and to prepare m encryption keys 
if kg for each i, j pair. It is clear that if call k has taken place or a connection has been 
unsuccessful, then key if kg must be destroyed. 

The enterprise server serves the main role in call encryption key generation and the 
initial distribution. Furthermore, the distribution of keys occurs at the premises of the 
enterprise. If the number of employees 12 is not very large (not exceeding, for exam¬ 
ple, 100 ) and an attack that blocks calls is not expected, then the protocol offered is 
practically secure. 

A more severe risk is connected to the key generation algorithm. The following sit¬ 
uation could be an example of risk exposure. Let’s suppose that the procedure generates 
only keys, when it was advertised to users that the generator would generate 2 ^®® 
independent keys. The user cannot identify the fraud in a direct way, because it could 
take quite a lot of time to test the generator. Just imagine if, for example, each key is 
generated in one second. This is why we recommend that enterprises should create key 
generators themselves. 

If there is no generator software available, then key generation can be done manu¬ 
ally. Anyway each cryptosystem need keys with specific properties. We shall demon¬ 
strate the method how can be generated a key that contains approximately equal number 
0 and 1 in the key. A key could be generated using a card deck. Take 52 cards, mix them 
up, and throw one or two cards out. Take the cards from the deck one by one. If a card is 
red, then choose 0. If a card is black, then choose 1. A key (or part of key) with a length 
of 50 or 51 is generated. Repeat the whole procedure just described again and combine 
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the parts. A key with a length of 203 (4 parts combined) is considered to be practically 
secure. 

The method suggested could be seen to be comically primitive, and thus not secure 
by a non-specialist. But, 



4 " 



This is well known asymptotic approximation (see, for example (WEB, e)). For standard 
52-card deck n = ^ = 26. We recommend to throw one or two cards out therefore it 
is possible to generate about 


(425)4 

(7r25)2 


>2187 


different keys using the suggested method. Such a method could be used by a user who 
needs to encrypt 2-3 documents. But this method is not suitable for an enterprise which 
needs to encrypt thousands of documents each day. 


4 Conclusions 

We have adapted Shamir’s approach to share a secret (Shamir (1979)) for encryption 
key management in a mobile environment. An encryption key of sufficient length is 
generated and split into two independent parts. This is used to encrypt a document 
or voice call. Part of the key is kept in a smartphone, while another part is kept in a 
Bluetooth or NFC wristband. Part of the key is kept in the wristband which is why 
decryption of a document is not possible without that part. 

The fact that part of the key is kept in a wristband in an encrypted way prevents 
an attacker from gaining any significant benefit, even if traffic between the wristband 
and smartphone is intercepted. That is why a user should not be worried if someone 
illegally intercepts that traffic. Taking Bluetooth characteristics into consideration, the 
illegal interception of traffic is possible from quite a long distance. NFC technology is 
less vulnerable to this risk. 

A secure server could be used instead of a wristband for the needs of enterprises. 
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